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FOREWORD 


The  Data  Process ing/HAPDAR  Field  Test  Facility  was  created  by  adding  an 
IBM  360/65  Computer  and  specially  developed  software  to  the  existing  Sperry 
Rand  HAPDAR  (Hardpoint  Demonstration  Array  Radar)  at  White  Sands  Missile 
Range,  New  Mexico.  The  integrated  combination  of  computer,  software,  and 
phased  array  radar,  resulted  in  a  system  capable  of  controlled  search  and 
track  operations  against  missile  and  aircraft  targets  at  WSMR.  The  initial 
creation  of  the  facility  occurred  under  Contract  DAHC60-72-C-0032  which  ended 
18  December  1972.  A  description  of  the  Facility  appears  in  the  Final  Technical 
Report  prepared  by  RCA,  and  issued  under  that  contract  as  CDRL  Sequence  No, 
A006. 


Oebi^ging  and  initial  operation  of  the  Data  Process  ing/HAPDAR  Field  Test 
Facility  occurred  under  the  present  contract  (DAHC60-73“C“0035) •  This  contract 
was  originally  written  to  cover  the  period  I8  December  1972  to  30  June  1973, 
and  a  final  report  was  issued  as  Contract  Data  Item  A002.  In  the  meantime, 
however,  the  contract  v/as  extended  to  30  September,  1973,  mainly  to  permit 
completion  of  a  Passive  Jammer  Locator  Field  Test  prior  to  deactivation  of  the 
entire  Facility.  The  present  report  describes  RCA  activity  at  the  Facility 
for  the  three-month  period  30  June  to  30  September  1973. 
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INTRODUCTION 


Contract  DAHC60-73"C-0035  was  originally  scheduled  to  end  on  30  June  1973, 
and  a  Final  Report  was  issued  as  Contract  Data  Item  A002.  In  the  meantime 
however,  the  contract  was  extended  for  three  additional  months,  and  the  present 
Final  Report  is  being  issued  to  cover  the  three-month  extension.  Issued  as 
Contract  Data  Item  B002,  the  present  report  describes  activity  at  the  Data 
Process ing/HAPDAR  Field  Test  Facility  during  the  period  I  July  I‘j73  to 
30  September  1973.  The  activity  involved  the  HAPDAR  and  the  IBM  360/65  com¬ 
puter,  both  owned  by  ABMDA  and  operated  at  White  Sands  Missile  Range,  New 
Mexico.  The  computer,  associated  hardware,  and  related  softv/arc  v/ere  originally 
installed  and  developed  under  a  previous  contract,  DAHC60-73~C-0032.  Several 
radar  and  tactical  data  processing  experiments  were  performed  using  the 
DP/HAPOAR  facility. 

The  activities  performed  during  July  through  September,  1973,  were  as 
fol lows : 

(1)  Support  the  Passive  Jammer  Locator  Field  Test  efforts  by  Syracuse 
University  Research  Corp.  under  their  Contract  F30602-72-0075. 

(2)  Provide  data-process ing  services  to  support  using  agencies, 

U.S.  Army  Safeguard  System  Evaluation  Agency  (SAFSEA)  and  U.5.  Army 
Combat  Development  Command  Air  Defense  Agency  (USACDCADA) , 

(3)  Provide  support  to  insure  an  efficient  turnover  of  equipment  and 
software  to  the  ABMDA  Field  Array  Radar  (AFAR)  project. 


This  report  reviews  the  above- listed  activities.  A  summary  of  the 
DP/HAPDAR  program  is  presented,  with  technical  conclusions  and  recommendations, 
A  list  of  primary  items  of  documentation  delivered  is  provided. 


SECTION  2 


TECHNICAL  EFFORT  DURING  THE  REPORT  PERIOD 

2.1  SUPPORT  OF  PASSIVE  JAMMER  LOCATOR  (PJL)  EXPERIMENTS  BY  SYRACUSE 

UNIVERSITY  RESEARCH  CORPORATION  (SURC) 

A  principal  use  of  the  DP/HAPDAR  facility  during  the  report  period  was 
to  support  the  SURC  PJL  tests.  The  PJL  tests  involved  positioning  the  HAPOAR 
and  RONDO  receive  beams  at  particular  locations  in  real  time.  Additionally, 
radar  returns  with  special  PJL  returns  were  recorded  on  the  360/65  tape  drives. 

To  accomplish  the  above  functions,  the  experiment  team  of  RCA,  SURC,  and 
Sperry  utilized  the  OP  software-package  real-time  operating  system  and  its 
associated  input/output  functions.  The  normal  HAPDAR  Tact i cal  software 
package  was  replaced  with  the  SURC  PJL  experiment  software.  The  PJL  software 
communicated  with  the  Real-Time  Execuitve  (BMDOS)  using  the  same  commands  as 
originally  designed  in  the  Execuitve.  Data  recording  in  real  time  was  accom¬ 
plished  by  using  the  HAPDAR  real-time  tape  output  (WRITDL)  program  to  record 
the  desired  parameters. 

During  the  report  period,  data  reduction  and  program  development  was 
accomplished  by  SURC  personnel  utilizing  the  IBM  360/65  machine. 

During  this  period  RCA  supported  SURC  by  supplying  operations  personnel 
as  required  and  by  providing  assistance  in  the  use  of  the  BMDOS  and  related 
software.  One  major  activity  in  this  area  was  the  conversion  of  data  tapes  to 
be  compatible  with  the  SURC  Sigma-5  computer  during  the  terminal  phases  of  the 
contract. 

All  SURC  software  has  been  preserved,  utilizing  the  Archive  program, 
so  that  subsequent  data-reduction  may  be  performed  on  the  360/65  at  RCA 
Moores  town. 

Details  of  the  support  requirements  are  found  in  the  SURC  document  cited 
in  Reference  3.  The  RCA  support  effort  is  presented  in  Appendix  3. 
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2.2  DATA  PROCESSING  SUPPORT  TO  SAFSEA  AND  USACDCADA 


Operations  and  technical  support  was  provided  to  the  using  agencies, 

SAFSEA  and  USACDCADA,  during  the  report  period.  No  unusual  problems  or  events 
occurred  during  the  period  of  this  report.  A  summary  of  computer  usage  is 
presented  in  Subsection  2. A.  The  operation  of  the  computer  was  completed  on 
30  September  I973>  Teardown  of  the  system  for  shipment  started  on  I  October 
for  shipment  to  the  AFAR  project. 

2.3  AFAR  TURNOVER 

In  connection  with  the  AFAR  Program,  ABMDA  had  decided  to  utilize  the 
IBM  360/65  Computer  at  the  HAPOAR  Site  as  the  Radar  Control  Computer  for  the 
AFAR  development.  This  decision  precipitated  activity  at  the  site,  to  prepare 
for  the  movement  of  hardware  and  software  from  the  site  to  the  RCA  plant  in 
Moores  town,  N.J. 

Specific  requirements  were  that  a  final  version  of  the  HAPDAR  software 
be  defined  and  prepared  for  transfer  to  AFAR  software  functions.  Additionally, 
it  was  felt  that  timing  information  of  HAPDAR  software  functions  was  needed 
on  the  selected  versions  to  aid  in  AFAR  software  design  decisions.  To  ac¬ 
complish  this,  two  tasks  were  initiated: 

(a)  Develop  an  'Archive'  program  to  aid  in  establishing  the  HAPDAR  final 
program  versions  and  AFAR  baseline  versions.  This  program  was  used 
to  provide  an  AFAR  Baseline. 

(b)  Develop  timing  macros  that  would  measure  execution  times  of  selected 
HAPDAR  program  modules  and  execute  these  with  HAPDAR  real-time 
software. 

(c)  Develop  a  move  plan  for  the  hardware  and  software. 

The  Archive  program  was  developed  and  used  to  produce  final  program  versions 
for  HAPDAR. 
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The  HAPDAR  final  versions  are  shown  in  Appendix  I  with  Archive  output. 

The  Archive  system  will  be  used  on  the  AFAR  project  as  a  major  configuration 
management  tool. 

A  timing  study  of  software  functions  on  HAPDAR  was  conducted  during  the 
HAPDAR/AFAR  Turnover  to  aid  in  AFAR  software  design  decisions.  A  previous 
HAPDAR  Timing  Model  (Refe'^ence  1)  indicated  the  need  for  additional  data  to 
substantiate  the  model  assumptions.  Since  the  hardware  monitoring  equipment 
(sum)  was  not  available  to  perform  this  function,  it  was  decided  to  generate 
software  macros  that  were  the  equivalent  of  SUM  equipment.  The  design  intent 
of  the  macros  was  to  minimize  the  execution  overhead.  These  macros  have  been 
designed,  tested  and  are  operational.  They  are  described  in  Appendix  3. 

A  move  plan  was  developed  and  executed  during  this  period  to  insure 
that  a  successful  transition  of  hardware  and  software  to  AFAR.  All  elements  of 
this  plan  were  completed  by  September  30,  1973  as  scheduled. 

2.k  SUMMARY  OF  COMPUTER  USAGE  DURING  REPORT  PERIOD 

Table  2~l  presents  a  summary  of  jobs  and  hours  of  utilization  by  various 
users  of  the  DP/HAPDAR  Facility.  This  accounting  does  not  include  time 
that  the  system  was  operated  in  real-time  with  the  radarj  the  table  shows  only 
those  jobs  and  hours  in  c  standard  data  processing  mode  under  OS-360. 

TABLE  2-1.  SUMMARY  OF  360/65  COMPUTER  USAGE 

July  August  September 


User 

Jobs 

Hours 

Jobs 

Hours 

Jobs 

Hours 

ABMDA 

1226 

106.3 

998 

68.1 

878 

93.0 

USACDCADA 

213 

5.8 

I3k 

16.1* 

O 

CM 

24.1 

USASAFSEA 

352 

31.7 

CO 

143.0 

227 

24.3 

SURC 

513 

61. 1 

329 

3'*. 9 

Usk 

60.3 

*USAMIS0 

-- 

— 

201 

30.9 

TOTALS 

2316 

20A.9 

2010 

161.5 

2121 

232.4 

Grand  Total  -  6AA7  Jobs  -  598.8  hours 
*  USAMISO  did  not  run  in  July  and  August. 
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SECTION  3 


CONCLUSIONS  AND  RECOMMENDATIONS 

This  section  briefly  discusses  the  DP/HAPDAR  contract  effort  and  present; 
overall  conclusions  and  recommendations  which  have  arisen  based  on  experience 
with  the  program  list  of  all  reports  delivered  by  RCA  is  included. 

3.1  TECHNICAL  CONCLUSIONS 

(1)  Experience  shows  the  practicality  and  economy  of  using  a  software 
simulation  of  an  actual  radar  (in  this  case,  HAPDAR)  in  order  to 
test  real-time  control  and  tactical  software.  Simulation  of  the 
actual  HAPDAR  was  accomplished  using  an  External  Environment 
Simulator  (core-resident  in  the  IBM  360/65)  and  also  using  the 
SACS-H  Simulation  (located  in  Huntsville,  Ala.,  and  connected  to 
the  OP/HAPDAR  Site  via  data  link).  Extensive  use  of  the  EES  was 
made  in  testing  the  changes  made  in  the  tactical  software  for 
conduct  of  various  experiments. 

(2)  Execution  of  programs  in  both  real-time  and  interrupted  real-time 
was  made  utilizing  the  same  software  configuration,  with  a  simple 
software  switch  to  control  the  mode.  This  was  accomplished  at 
HAPDAR  with  EES  and  the  real-time  system. 

(3)  The  support  software  is  highly  important  in  a  multiple-user  site 
environment.  Ease  in  making  and  testing  changes  to  baseline  soft¬ 
ware  demands  a  systematic  means  for  controlling,  recording,  and 
documenting  the  changes.  The  Library  Management  Facility  developed 
under  PHSD,  and  associated  software  that  was  developed  at  DP/HAPUAR 
is  a  valuable  asset  for  control  of  changes.  Fortunately,  it  is 
directly  transferrable  to  AFAR. 

(A)  The  Ballistic  Missile  Defense  Operating  System  (BMDOS)  from  PHSD 
was  modified  to  operate  in  real-time  or  interrupted  real-time  and 
was  used  successfully  in  several  experiments.  It  is  another  resource 
that  will  be  transferred  to  AFAR  and  used  basically  intact.  The 
principal  changes  that  were  made  were  real-time  input/output  functions, 
and  these  will  be  extended  for  use  in  AFAR. 


(5)  The  design  of  compute r“Con trolled  radar  systems  must  consider 
hardware  aids  to  detect  error  conditions  in  execution  of  radar 
commands  which  cannot  be  detected  by  software  means  within  a  given 
command  frame.  This  feedback  will  prevent  the  occurrence  of  system 
'Hangs'  that  were  experienced  on  HAPOAR  where  no  feedback  of  error 
conditions  to  360  existed.*  Software  recovery  at  HAPDAR  from  Hangs 
consisted  of  using  timer  interrupts  to  break  the  deadlock  and  to 
ignore  any  data  collected  in  the  frame  concerned.  This  is  not  the 
way  to  recover.  Extensive  data  has  been  documented  on  this  problem 
in  other  reports. 

(6)  The  Kalman  filter  developed  for  PHSC  and  used  at  OP/HAPOAR  was  not 
designed  for  powered  (accelerating)  targets.  Attempts  to  tracts 
powered  vehicles  in  HAPDAR  experiments  required  software  logic  tr. 
test  acceleration  in  range  before  calling  the  Kalman  filter.  The 
target  is  kept  in  polynomial  track  until  the  acceleration  term 
becomes  less  than  the  value  tolerated  by  the  Kalman. 

(7)  The  development  of  real-time  software  for  HAPOAR  resulted  in  a 
framework  and  software  transition  for  the  AFAR  project  for  the  Radar 
Control  Computer.  This  is  possibly  the  most  important  output  of  the 
DP/HAPDAR  contract.  The  Real-Time  Operating  System  (BHDOS)  is  a 
seasonsed  software  package.  The  IMF  system  for  program  development 
is  a  highly  useful  tool  and  is  being  improved  for  AFAR.  Experience 
in  a  multiple-user  environment  is  highly  useful  in  the  transition 

to  the  AFAR  environment  at  KMR. 

3.2  RECOMMENDATIONS 

(I)  Future  radar  designs  should  be  reviewed  in  light  of  DP/HAPDAR 
experience  for  the  following  items: 

*The  problem  of  "system  hangs"  is  described  in  the  Final  Report  covering 
activity  through  June,  1973.  and  issued  as  Data  I  tern  A002  under  this 
contract. 


(a)  Methods  of  preventing  possible  deadlock  conditions  (Hangs)  in 
both  hardware  and  software  should  be  the  subject  of  design 
reviews.  Quick  non-disrupt ive  recovery  is  required. 

(b)  A  unique  identification  on  each  type  of  radar  return  should 
be  a  design  requirement.  Additionally,  a  method  of  framing 
the  returns  from  a  single  dwell  (look)  should  be  employed 
allowing  blocking  of  several  dwells  in  a  command  buffer 
without  complicating  software  to  pack  and  unpack  radar  orders 
and  resulting  returns. 

(c)  Separate  I/O  channels  for  radar  orders  and  returns  are  a 
desirable  feature. 

(d)  Buffering  in  the  radar  control  unit  is  a  desirable  feature. 

The  RCI  at  HAPDAR  contained  no  buffering  capability,  thus  fo-'cing 
the  360/65  to  have  dual  buffers  for  both  orders  and  returns 
and  to  operate  in  a  '3“ring  circus'  rather  than  a  '2-ring 
circus'.  The  number  of  rings  in  the  circus  sets  the  maximum 
block  size  with  a  given  filter  update  rate.’- 

(e)  A  byte-oriented  command  word  structure  is  desirable  to  aid  the 
packing  and  unpacking  of  orders  and  commands  from  and  to 
computational  forms  used  in  software. 

2.  The  Kalman  filter  design  and  criteria  for  accelerating  targets 
should  be  studied.  The  effect  of  MIRV's  on  any  filters  and 
algorithms  for  search  and  acquisition  should  be  studied.  HAPDAR 
data  is  available  to  test  filters  in  a  realistic  accelerating-target 
environment. 


*The  "3-ring  circus"  concept  is  described  in  the  Final  Report  issued  as  Data 
Item  A002  under  this  contract  and  covering  activity  throughJune  1973. 
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SECTION  4  . 


SUMMARY  OF  DATA  ITEMS  DELIVERED 

This  section  summarizes  the  data  items  prepared  during  this  and  preceding 
DP/HAPDAR  contracts. 

Table  4-1  lists  the  documentation  furnished  under  the  present  contract. 

Table  4-2  lists  documentation  submitted  by  RCA  Corporation  to  SDC 
Corporation  under  SDC  Subcontract  73"323.  In  this  effort  the  prime  contract 
is  DAHC-73-C-0055. 

Table  4-3  lists  documentation  delivered  by  RCA  under  Contract  DAHC60-72-C-0032 , 
the  first  contract  for  creation  of  the  Data  Process ing/HAPDAR  Field  Test  Facility. 

TABLE4-1.  DATA  DELIVERABLE  TO  ABMOA 
under 

CONTRACT  0AHC60-73-C-0035 

Date  Item  Title  No.  of  Reports 


AOOl 

Program  Plan 

Once 

BOOl 

Program  Plan 

Once 

A002 

Final  Technical  Report 
for  period  ending  6/30/73 

Once 

A003 

Source  Programs  &  Data 

Once 

B002 

Final  Technical  Report 

Once 

A  items  cover  from  12/18/72  to  6/30/73 
B  items  cover  7/1/73  to  9/30/73* 


TABLE  4-2 

RCA  Subcontract  Ti-'iH 
Data  I  terns  Delivered 
to  SDC  under 
Contract  DAHC-73-C-0055 


1 .  Letter  Report  to  SDC  as  Da^a  I  tern  1.0, 

under  RCA  Subcontract  No.  73“323,  entitled  "HAPDAR-SACS-H  Simulation 
Experiments,"  29"30  June  1973- 

2.  Data  Requirements  Plan  to  SDC  as  Data  Item  2.0, 

Under  RCA  Subcontract  No.  73“323.  Report  covers  the  26  April  DP-3 
Athena  Experiment,  30  April  DP-1  Sphere  Drop  Experiment,  25  May  DP-i 
and  DP-2  Sphere  Drop  Experiments. 

3 .  Letter  Report  to  SDC  as  Data  I  tern  3.0, 

under  RCA  Subcontract  No.  73"323,  entitled  Sphere  Drop  Mission  of 
25  May  1973. 

4.  Operations  Procedure  Plan  -  Athena  Miss'on  of  26  April  1973i 
to  SDC  as  Data  I  tern  4.0,  under  RCA  Subcontract  No.  73"323. 

5.  Operations  Procedure  Plan  -  DP-1  Sphere  Drops  of  30  April  1973, 
to  SDC  as  Data  Item  4.0,  under  RCA  Subcontract  No.  73"323> 

6.  Operations  Procedure  Plan  -  Sphere  Drop  Mission  of  25  May  1973, 
to  SDC  as  Data  I  tern  4.0,  under  RCA  Subcontract  No.  73*323- 

7 .  Operations  Procedure  Plan  -  Sphere  Drop  Mission  of  25  May  1973> 

Supplement  No.  1,  to  SDC  as  Data  Item  Vo,  under  RCA  Subcontract  No.  73-323. 

8.  Monthly  Activity  Reports, 

to  SDC  as  Data  I  tern  9*0,  under  RCA  Subcontract  No.  73"323,  to  cover  the 
periods  through  31  March  1973,  30  April  1973  and  8  June  1973. 

9.  Test  Evaluation  Reports, 

Data  I  tern  5.0 

10.  'Summary  of  Recorded  Data  on  Targets  of  Opportunity', 

Data  Item  7.0 
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TABLE  4-3 

Data  Deliverables  to  ABHDA 


Data  Item 
AGO  I 
A002 
A003 
A004 
A005 
A006 
A007 

Aooa 

A009 

AGIO 

AOII 

AGI2 


Under 

Contract  DAHC60-73-C-0032 
Title 

Cost  Planning  and  Appraisal  Chart 

Contract  Funds  Status  Report  DD-I586 

Program  Plan 

Letter  Progress  Reports 

Quarterly  Technical  Reports 

Final  Report 

Special  Technical  Report: 

Software  Capability  Description  (SCD), 
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SECTION  6 


GLOSSARY  OF  TERMS 

Archive  -  A  program  developed  to  list  all  versions  of  a  load  module 
and  preserve  it  on  tape. 

AFAR  -  ABMDA  Field  Array  Radar  -  A  new  solid-state  Radar  system. 

AL/I  -  Analyst  Language  I.  A  high-level  language  for  BMD  applications. 

BMD  -  Ballistic  Missile  Defense 

BMDOS  -  Ballistic  Missile  Defense  Operating  System. 

BSU  -  HAPDAR  Beam  Steering  Unit. 

EES  -  External  Environment  Simulator. 

HAPDAR  -  Hard  Point  Defense  Array  Radar. 

HANG(s)  -  A  term  denoting  a  deadlock  situation  in  a  real-time  system. 

KMR  -  Kwajalein  Missile  Range 

LMF  -  Library  Management  Facility 

Master  -  HAPDAR  intial ization  program 

MIRU  -  Multiple  Independent  Reentry  Vehicle. 

OS-36O  -  Operating  System  360.  The  Executive  Program  for  360/65 
Precision  Acquisition  System. 

PHSD  -  Preliminary  Hardsite  Demonstration. 

PJL  -  Passive  Jammer  Location. 

PJLRT  -  Passive  Jammer  Location  Real  Time  Program. 

PJLSIM  -  Passive  Jammer  Location  Simulator 

RCI  -  Radar  Computer  Interface.  Interface  for  36O  to  HAPDAR. 

RONDOA  -  Receive  Only  Radar  Antenna  used  in  PJL  experiments. 

SUM  -  System  Utilization  Monitor,  used  to  measure  computer 

and  software  performance, 

SURC  -  Syracuse  University  Research  Corporation 

TIME  ON  and  TIME  OFF  -  Macros  developed  to  measure  program  execution  times. 
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VDP  -  HAPDAR  Video  Data  Processor. 

WRITDL  ■  A  real  time  recording  program. 
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APPENDIX  1 


Final  HAPDAR  Program  Versions 

Tfiis  Appendix  details  release  information  and  program 
versions  for  thd  HAPDAR  Real-Time  Software  system  at 
shutdown  on  September  28,  1973* 


DATE: 


October  2,  1973 


SUBJECT: 

FROM: 

TO: 


System  Release  Notice 
WGS/LC 

HAPDAR-AFAR  Distribution 

System  Purpose:  This  software  system  operates  the  HAPDAR  radar 
in  real-time  and  the  EES  simulator  in  interrupted  real  time.  It 
also  contains  the  special  template  software  the  the  DP  experiments. 

Special  Features:  This  release  contains  a  standard  CTDS  for  full 
volume  coverage.  A  single  load  module  operates  both  Real-time  and 
EES.  This  is  the  final  HAPDAR  version. 

Documentation:  Partial  Documentation  from  the  Archive  system 
showing  Versions  is  attached. 

Release  Tape  Description: 

Date  Created:  26  Sept.  73 
Tape  Label:  SEP2(j)T 


Load  Module(s) : 


Data  Set 


Member  Name 


Entry  Name 


2  )9iJ 


►  =  ill 


APPENDIX  2 
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Timing  Macros 

This  Appendix  contains  details  concerning  special  macros  that 
were  developed  to  aid  the  timing  of  HAPDAR  software  functions 
as  a  replacement  for  Hardware  monitoring  (SUM)  equipment  that 
was  used  for  earlier  timing  experiments  by  Texas  Instruments 
in  Reference  2. 
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Timing  Macros 


TIME  ON  -  TIME  OFF 


L _ fioneral 

In  order  to  obtain  software  timing  statistics  approximating  the  output 
of  the  hardware  SUM  equipment  used  with  the  IIAPDAR  Software,  it  is  netessury 
to  insert  the  timing  macros-TIMEON  and  TIMEOFF  into  each  module  or  section 
of  code  to  be  timed. 

In  order  to  envoke  the  TIMEON  and  TIMEOFF  macros  at  compile  time,  a  global 
parameter  &TIMER  must  be  defined  as  follows: 

GBLC  &TIMER 
&TIMFR  SETC  'ON' 

If  the  above  code  is  not  included,  generation  of  timing  macros  will  be 
suppressed.  This  modification  allows  the  user  to  suppress  the  expansion  of 
the  macros  without  removing  the  actual  statements  from  the  code. 

Each  riMEON-TIMEOFF  Macro  pair  is  given  (by  the  Configuration  Manager)  a 
unique  identifier  (1-99)  which  corresponds  to  an  entry  in  the  AFAR  Timing 
Information  Table  (ATIT)  residing  within  the  code  for  MASTER  (BMDOS  Initial¬ 
ization).  Statistics  are  accrued  in  the  table  until  the  end  of  the  BMDOS 
run  (EES  or  Real-Time),  at  which  time  the  termination  routine  (FINIS)  is 

entered.  A  modification  to  FINIS  will  calculate  from  the  timing  statistics 

« 

available  the  average  time  for  each  execution  as  well  as  the  Standard  Devia¬ 
tion.  This  data  will  be  printed  out  at  the  end  of  the  run. 
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The  current  execution  time  (timing  overhead)  for  each  TIMEON-TIMEOFF  pair 
is  approximately: 

TIMEON  21.85  u  sec. 

TIMEOFF  34.81  n  sec. 

TOTAL  56.66  p  sec. 

11.  [j mi _nj_ Acti vati on  Parameters 

The  timing  code  while  it  is  resident  in  each  module  to  be  timed,  will  not 
be  executed  unless  the  timing  table  (ATIT)  entry  for  that  module  or  section 
of  code  has  been  turned  on  via  the  following  Run  Time  input  parameter  added 
to  the  "OPTiri"  BMDOS  Data  Set: 

Column_l _ 10 _ 80 

TIMING  n.nj-n^.n^.n^,. . .etc.  j 

The  parameter  "TIMING"  must  appear  in  the  data  card  starting  in  column  1, 
followed  by  the  numbers  of  the  entries  to  be  turned  on  starting  in  column  10. 
Entries  must  be  separated  by  a  comma  (,),  and  a  range  of  entries  may  be 
specified  by  the  first  and  last  numbers  in  the  range  separated  by  a  dash 
(-).  A  blank  (ti)  terminates  the  parameter  field. 

Example: 

TIMING  1,3-8,11,21-25,50-99 

An  additional  Data  Definition  (DD)  card  (detailed  below)  must  be  added  to 
the  run  deck  to  allow  printing  of  the  run-statistics. 

//TIMING  DD  SYS0UT=A 
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1.0  TIMLON  S  lid  I  omen  t 


The  TIMLON  Slateiiient  initiates  timing  within  a  module  by  crcatimj  a  poriud 
START  time  (START  time  =  Six  Hour  Pseudo  Clock  Time  -  CPU  Clock  Time)  and 
updating  the  corresponding  field  in  the  ATAR  Timing  Information  T<it)lo  (Afll) 
Entry  identified  with  the  TIMEON  Statement.  Also  an  event  counter  i'^  incrf;- 
mentcd  by  1  every  time  a  TIMEON  is  processed. 


label 


TIMEON 


entry-identifier 


i,COMREG={j'^J^] 


YES 


YES 

.RECS-fJ';i 


a.  Entry-identifier 

Number  (1-99)  corresponding  to  the  relative  position  of  the  entry  within 
the  AFAR  Timing  Information  Table. 

b.  C0MREG={Jq^} 

This  parameter  is  optional.  If  COMREG=YES  is  specified,  the  generated 

code  will  assume  tbat  the  base  register  for  the  COMREG  table  has  been 

established  somewhere  else  in  the  code.  If  C0MREG=N0,  or  the  operand 

is  omitted  the  macro  generation  will  establish  Register  14  as  a  base 

register  (and  DROP  14  at  the  end  of  the  generation). 

YES 

c.  SSM={^) 

This  parameter  is  optional.  If  SSM=N0  is  specified,  no  code  will  be 
generated  to  disable  and  enable  interrupts  before  and  after  timing  calcula¬ 
tions  are  made.  Otherwise,  interrupts  will  be  turned  off  (SSM  *+l)  before 
and  turned  on  (SSM  VEXITPSW)  after  the  calculation  is  made. 

d. 

This  parameter  is  optional.  If  REGS=YES  is  specified.  Register.  14,  16,  0, 

1  will  be  saved  into  and  restored  from  a  save  area  wittiin  the  macro  gen¬ 
eration.  Otherwise,  the  contents  of  those  registers  will  not  be  guaran fet-d. 
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Note:  Two  TIMEON  statements  with  the  same 


entry-identifier  cannot  be  issued  in 


a  row. 
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2.0  TIMEOFF  Statement 

The  TIMEOFF  Statement  calculates  the  time  for  the  end  of  a  period  (END  Tiiik.-- 
Six  Hour  Pseudo  Clock  Tiine-CPU  Clock  Time)  and  subtracts  that  time  from  the  START 

I 

time  (calculated  by  the  TIMEON  statement)  to  obtain  the  duration  of  the  period. 

Then  the  fields  within  the  AFAR  Timing  Information  Table  correspond! luj  to  the 

sum  of  the  periods  calculated  (EaT)  and  the  sum  of  the  squares  of  the  differences 

2 

between  the  calculated  period  and  a  representative  period  ^P* 

da  Led. 


label 

TIMEOFF 

entry-identifier  .C0MREG={,^^^)  ,5SM={S 

YFS 

.REGSH^'y") 

L  -  J 

a. 


b. 


c. 


Entry- identifier 

Number  (1-99)  corresponding  to  the  relative  position  of  the  entry  within 
the  AFAR  Timing  Information  Table. 

COMREG={JJq^ 

This  parameter  is  optional.  If  COMREG=YES  is  specified,  the  generated 
code  will  assume  that  the  base  register  for  the  COMREG  table  has  been 
established  somewhere  else  in  the  code.  If  C0MREG=N0,  or  the  operand 
is  omitted  the  macro  generation  will  establish  Register  14  as  a  base 
register  (and  DROP  14  at  the  end  of  the  generation). 


This  parameter  is  optional.  If  SSM=N0  is  specified,  no  code  will  be 
generated  to  disable  and  enable  interrupts  before  and  after  timing  calcula¬ 
tions  are  made.  Otherwise,  interrupts  will  be  turned  off  (SSM  *+l)  before 
and  turned  on  (SSM  VEXITPSW)  after  the  calculation  is  made, 
d.  REGS=()“) 

This  parameter  is  optional.  If  REGS=YES  is  specified.  Registers  14,  IS,  0, 
1  will  be  saved  into  and  restored  from  a  save  area  within  the  macro  gen¬ 


eration.  Otherwise,  the  contents  of  those  registers  will  not  be  guaranteed. 
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Note: 


Two  TIMEOFF  statements  with  the  same  entry-identifier  can  not  be  issued 


in  a  row.  Also  a  TIMEOFF  may  not  be  executed  without  a  previous  TIMFON 
statement  with  the  same  entry-identifier. 
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3.0  Al'AK  Timing  Information  Table  (ATIT) 


1 


The  Timing  Information  Table  contains  99  entries,  each  consisting  of 
6  full  word  data  fields  (detailed  below).  The  table  is  resident  in  MASTER 
and  is  generated  by  adding  an  inline  macro  instruction  (also  named  ATIT  with 
no  parameters) .  The  table  is  initialized  by  modifications  in  the  suliroutine 
VLXWIOR  located  in  MASTER  and  entries  are  turned  on  via  run-time  parameters. 

Timing  Information  Table  Entry 

BYTE  (3 _ 4 _ 8  9 _ 12 _ 16 _ 20 _ ^3 


AT  I  START 

— 

ATIACCUM 

F 

L 

ATI  EVENT 

ATIT2 

ATLTI 

ATISTD 

A 

G 

■  Field 

Length 

Description 

ATISTART 

4  Bytes 

(Binary)  . 

1 

Period  start  time  stored  by  TIMEON  and  used 
by  TIMEOFF  to  calculate  duration  START  TIME= 

Six  Hour  Pseudo  Clock  Time  -  System  Timer 

ATIACCUM 

4  Bytes 
(Binary) 

The  sum  of  the  times  recorded  for  all  accesses 
of  the  module  (or  TIMEOM-TIMEOFF  pair) 

S.  =  ,  T 

1  n=l  n 

FLAG 

1  Byte 
(Binary) 

Status  indicator; 

x'0!3'  -  Entry  Inactive 

x'80'  -  Entry  Active 

x'40'  -  TIMEON  has  been  Issued  (x'C0') 

x'20'  -  TIMEON  twice  in  a  row  (x'E0') 

x’10'  -  TIMEON  without  TIMEON  (x'90) 

ATIT2 

4  Bytes 
(Binary) 

The  sum  of  the  squares  of  the  differences 
between  the  calculated  time  interval  and  the 
second  time  interval  calculated  (the  first 
calculation  is  skipped  because  initializa¬ 
tion  time  throws  the  standard  deviation 
calculation  off. 

1 

C  rN  /T  T 

ATITI 

j 

4  Bytes 
(Binary) 

The  initial  time  interval  calculated  (T.) 

(see  description  for  All  12). 

:  f- 

ATISTD 


4  Bytes  This  field  contains  the  Standard  Deviation 

(Floating  Pt)  (updated  by  FINIS  only  at  tiie  completion 

of  the  niission-during  the  mission  it  is  used 
as  a  work  area  by  trie  TIMEOFF  Macro). 

0  =  jij^  (z||_j  (T^-T)^)  =  Std.  Deviation 
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RCA 

SUPPORT 

FOR 


PJL  EXPERIMENT 


TABLE  OF  CONTENTS 


PART  I  -  A  general  description  of  the  necessary  software  development 
and  software  support  required  of  the  RCA  Field  Test  Facility 
to  accomplish  the  integration  of  PJL  software  into  the  IIAIMJAR 
system. 


PART  II  -  A  detailed  documentation  of  the  PJL/BMDOS  software  integration 
routines . 
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PART  I 


CENTRAL  PJL  SUPPORT 


Three  distinct  modes  of  operation  of  the  PJL  experiment  are  supported 
by  the  FTP.  They  are: 

1.  Execution  of  the  PJLRT/PJLSIM  software  in  a  non-real-tiiiie 
environment  runnint)  under  the  control  of  OS- 

2.  Execution  of  the  PJLRT/PJLSIM  software  in  an  interrupted 
real-time  enviionniont  where  PJLRT  runs  under  ttie  control  of 
BMDOS  and  PJLSIM  runs  under  the  control  of  OS. 

3.  Execution  of  the  PJl.RT  software  in  a  real-time  envi ronment 
where  PJLRT  rufis  under  the  control  of  liHDOS  and  interacts 
with  a  real-world  as  sensed  tlirourih  reports  t  rom  IIAl’lJAK 
sub-units,  PJL  equipment,  and  RONDO  A  remote  r’adar. 


Each  of  these  three  modes  of  operation  required  the  development  of 
various  interface  software  and  support  softwar-e.  This  document  is  an 
attempt  to  show  the  scope  of  this  software  development  by  RCA  anJ  to  serve 
as  a  source  of  information  for  the  duration  of  the  PJL  experiment, 
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A.  RCA  Support  and  Development  for  Mode  1  (PJLRT/P.II  SIM  Under  OS) 

RCA's  primary  task  vfas  that  of  systems  support  to  help  SURC  proprammet s 
clear  up  any  incompatabi  1  i  ties  between  Si(|ma  IV  FORTRAN  and  IRM  360/CS  lORIRAN 
EXTENDLl),  and  to  aid  in  solving  various  JCL  problems. 

R.  RCA  Support  and  Development  for  Mode  2  (PJI.RT  Under  RMDOS,  PJl.SIM 

Under  OS) 

Since  PJLRT  and  PJLSIM  were  designed  to  communicate  through  only  one 
common  area,  they  lent  themselves  to  execution  in  an  IRT  environment  such  as 
was  developed  for  POST  PIISD.  To  accomplish  this  it  was  necessary  to  replace 
the  PJL  Driver  with  Wl.C  and  have  MASTER  call  various  SURC  supplied  initiali¬ 
zation  routines,  namely,  PJLINT,  PJLCON,  PJLSll,  and  PJLPRT.  Also,  it  was 
necessary  to  replace  the  SURC  I/O  software  with  FTf  1/0  software  routines, 
TAPESV  and  PJTAPE. 

It  was  at  this  stage  of  the  development  that  PJLRT  was  run  in  a  real¬ 
time  environment  under  the  control  of  BMDOS  for  the  first  time.  The  (iroblems 
that  resulted  were  primarily  due  to  differences  in  supporting  philosophies 
between  OS  and  BMDOS. 

C.  RCA  Support  and  Development  for  Mode  3 

Since  modes  1  and  2  verified  the  PJL  real-time  software,  mode  tliree 
was  mostly  verification  of  RCA's  I/O  interface  software. 

The  executive  for^  I/O  interfacing  is  PJLIO.  This  executive  along  with 
all  the  support  routines  pictured  in  Figure  1  comprise  the  bulk  of  the  RCA 
support  software  for  the  PJL  experiment. 

A  preliminary  PJLIO  real-time  process  was  established  usin()  a  dummy 
PJLRT.  In  this  manner  the  FTF  real-time  structure  was  quickly  debugiied. 

With  the  real-time  I/O  structure  fairly  well  established,  it  was  a 
simple  matter  to  execute  the  real  PJLRT  software. 


RCA  FTP  SOFTWARE  DEVELOPMENT 
FOR 

PJL  REAL-TIME  PROCESS  | 

If 

f 


PJL  10 

(s)* 

TTYOUT 

(S) 

RTUNPK 

(M) 

MASTER 

(M) 

PJLRTN 

(S) 

CLOCK 

(s) 

PJLRRA 

(S) 

TAPESV 

(M) 

CON  IN 

(M) 

RTPACK 

(M) 

CCUNPK 

(M) 

PJLORD 

(S) 

PJLPAS 

(S) 

PJLROA 

(S) 

PJIRIG 

(M) 

CONOT 

(M) 

PJLR 

(S) 

CCPACK 

(M) 

PJLO 

(S) 

For  a  description  of  the  precise  role  each  of  these  modules  plays 
in  the  real-time  system,  consult  part  II  of  this  document. 

D.  MISSION  TIME  SUPPORT 

All  PJL  users  get  BMD  mission  time  support  via  a  call  to  the  RCA 
subroutine,  CLOCK. 

See  CLOCK  documentation  for  further  details. 

E.  DATA  LINK  SUPPORT 

PJL  users  have  real-time  data  recording  capabilities  available  through 
the  use  of  the  RCA  supplied  TAPESV  subroutine.  See  TAPESV  documentation  for 
further  details. 

F .  INITIALIZATION  SUPPORT 

Successful  initialization  of  the  PJL  process  is  accomplished  in  the 
following  manner. 

1.  Files  PJLO  and  PJLR  are  zeroed  out  by  the  BMD  loader 

2.  MASTER  for  PJL  processing  calls  various  SURC  supplies  initiali¬ 
zation  routines  (PJLINT,  PJLPMI). 


*  (M  =  modified  from  basic  FTF  software;  S  =  created  from  scratch) 
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POST  MISSION  SUPPORT 

Through  use  of  the  RCA  supplied  PJTAPE  routine,  PJL  post  mission 
analysis  routines  have  access  to  the  PJL  data  recorded  by  various  calls 
to  TAPtSV. 


10  PRINTER  SlIPPpRi; 

It  is  desirable  during  real-time  for  PJL  analysts  to  he  able  to 
interrogate  and  print  various  critical  run  parameters.  This  capability 
is  supported  using  a  mixture  of  RCA/SURC/SPLRRY  soTtware. 

Rasic  communication  to  on-line  SURC  provided  display  programs 
is  handled  via  switches  on  the  HAPDAR  control  consol.  Ihese  protirams 
interface  with  RCA  supplied  I/O  programs  which  liandle  the  actual  formatting 
of  desired  messoges  and  transrnition  to  the  RCI.  A  SPERRY  provided 
characier  scan  program  resides  in  the  1218  which  will  formulate  line 
messages  and  print  as  necessary. 
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HAPDAR/PJL  ir.'TERFACE  SOFTWARE 
HAPDAR/PJL  DATA  FLOW 


flGL'RE  I  PJL  KISSICN  PJL  DATA 

IMTIALIZATION  ClCCK  PE'iATt.'J 


PART  II 


DETAILED  DOCUMENTATION 


A.  IDENTIFICATION  PJLIO  RT  CONTROL  EXECUTIVE 
TITLE:  PJLI/0  EXECUTIVE 
ID:  PJLIO 

PROGRAMMER:  T.  Royer 


B.  FUNCTIONAL  DESCRIPTION 


1.  General:  All  interfacing  with  PJL  software  is  done  by  way  of  two 
coiiiinon  blocks  called; 

PJLO  and  PJLR 

For  our  purposes  at  HAPDAR  PJLO  and  PJLR  are  viewed  as 
static  files. 

PJLO  — ►  orders  for  the  radar. 

PJLR  — ►  returns  from  the  radar. 

Basic  integration  EXECUTIVE  software  (PJLIO)  must  accom¬ 
plish  the  following  tasks. 

a.  Support  a  standard  3  ring  circus  cycle 

b.  Unpack  RADAR/PJL/RONDO/CONSOLE/RDT/PAS 

c.  Execute  PJLRT 

d.  Pack  RADAR/RONOO/PJL/CONSOLE  orders 

e.  Schedule  PJLIO  for  next  cycle 

f.  Provide  for  termination  and  execution  PMA  subroutine  be¬ 
fore  total,  control  is  returned  to  OS. 


a.  Support  standard  three  ring  circus 

PJL  THREE  RING  CIRCUS 

Cycle  n=0  MASTER 


Cycle  n=l 


PJLRT 

PACK  HAPHAR/RONDO/PJL/CC 
SCHEDULE  HRRTRN  FOR  N+1 
WAIT 


Cycle  n=2  XMIT  ORDERS  MADE  IN  CYCLE  n-1 

PJLRT 

PACK  HAPDAR/RONDO/PJL/CC 
SCHEDULE  HRRTRN  FOR  n+1 
WAIT 


Cycle  n=3  XMIT  ORDERS  MADE  IN  CYCLE  n-1 

UNPACK  RADAR/RONOO/PJL/CC/PAS/RDT 
FROM  CYCLE  n-2 

PJLRT 

PACK  HAPDAR/RONDO/PJL/CC 

SCHEDULE 

WAIT 


Cycle  n=4 


etc. 
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b.  UNPACK  RADAR/PJL/RONDO/CONSOLE/RDT/PAS 


Use  the  followinn  support  routines: 

RTIINPK  (unpack  radar) 

no  calling  sequence 

Input  is  the  standard  RAOARBIN 

PJLRTN  (unpack  PJL) 

Set  up  PJLBIN  (480  bytes) 

Call  PJLRTN  ( Input PJLBIN,,  Output PJLIN  <(li!/l) 
PJLRRA  (unpack  RONDO  A  returns) 

Make  sure  RONDO  is  properly  set  up  16  bytes 

Call  PJLRRA  (  Input RONDOBIN,  Output -►RON  DO  I  mn) 


CQNIN 


Check  first  GID  on  GIDQ 

(NOTE:  GIDS  will  be  replaced  by  mode  words  which  will  distinguish 
between  track  and  search  orders.  GIDQ  (MODES)  will  be  built  in 
ORORMAKE.  If  cottsole  input  from  the  RCl  was  requested  the  high 
order  bit  of  the  first  mode  word  in  the  GIDQ  will  be  set. 


No  calling  sequence  required,  just  call  CONIN. 
RDT  IRIG  Time 


Call  PJIRIG 


with  no  calling  sequence 


This  routine  will  be  called  when  valid  IRIG  message  time  is  known 
to  exist  in  the  message  buffer.  Unpacked  integer  data  will  be 
stored  into 


WISEC 

WIMS 

WITIMEi 


in  PJLR 


PJLPAS 


(unpack  PAS  data) 
Standard  calling  sequence 
Call  PJLPAS  (PASBIN,  PIRNGE) 


PIRNGE  is  the  FWA  of  the  integer  PJL  PAS  data  located  in 
PJLk  file. 

c.  Execute  PJLRT 

PJLRT  software  is  set  up  to  receive  'live'  returns  on  cycle  three 
as  dictated  by  the  three  ring  circus  cyclical  processing. 


4.  PACK  RADAR/PJL/RONDO/CONSOLE 

Use  the  following  support  routines: 

RTPACK  (pack  RADAR) 

No  calling  sequence  {if  orders  in  VDPOUT  Ulifl) 

PJLROA  (pack  RONDO  A  orders) 

Check  RONDOADO  for  =-l 

If  -1,  no  RONDO  scheduled  this  cycle 

If  +1,  use  stored  contents  as  output  address 

(NOTE:  RTPACK  will  have  left  room  for  both  RONDO  and  PJL  in  front  of 
the  first  order  if  necessary) 

RTPACK  will  maintain  RONDOADD,  PJLADD 

Calling  sequence 

Call  PJLROA  (RONDOTIZn,  RONDOADO) 

PJLORD  (Pack  PJL  equipment  orders) 

Check  contents  of  PJLADD. 

If  =-l,  no  PJL  this  cycle 

If  =  +,  use  contents  as  FWA  of  packed  output  from  PJLORD. 

Calling  sequence 

Call  PJLORD  (PJLOUTfZn .PJLADD) 


CONOT 


Check  CECCOP  in  PJLO 

If  set  pack  consol  by  calling  CONOUT  and  chain  to  end  of 
order  buffer 

If  not  set  forget  packing  consol 
Calling  sequence 
None 

HRORDR  was  not  used  but  was  incorporated  into  PJLIO  as  an  internal 
subroutine.  This  subroutine  is  called  ORDRMAKE  and  .is  called  immediately 
after  PJLRT; 
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e.  Schedule  PJLIO  for  Next  Cycle 


In  DMDCP(2),  BMDCP(3)  is  a  floating  point  mission  time  to  reschedule 
PJLIO. 

PJLIO  returns  in  BMDCP  (4),  (5)  a  floating  point  time: 
if  time  =  0.0,  everything  is  OK; 

if  time  >  0,  then  PJLIO  indicates  to  PJLRT  that  a  hang  condition 
was  encountered. 
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f.  Termination 


If  the  field  XEOM  is  set  greater  than  zero,  then  PJLIO  will  termi¬ 
nate  the  PJLRT  process,  call  PMA  subroutine  (quick  look  post  mission 
analysis  routine)  and  return  control  to  OS. 
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2.  Key  integration  details: 


PJL  software  interfacing  has  been  designed  to  have  a  minimum  of  v 

interaction  between  modules  for  simplicity  sake.  Some  interaction  was 
necessary  as  briefly  highlighted  below: 

1.  Consol  Pack/Unpack  interaction 

The  CC  external  function  consol  word  will  be  valid  in  only  the  last 
order  to  HAPDAR.  Previous  CC-EF  words  are  set  to  zero  conditions. 

If  CECCOP  is  set  then  PSL/0  knows  to  pack  and  chain  consol.  In 
addition  the  CECCIP  bit  will  be  packed  into  the  highest  bit  of  the  first 
niode/wordin  the  current  GIDQ. 


2.  PJL,  RONDO  schedule 

When  either  PJLOUT  Hill  or 

RONDO!  Hin  or  both 

are  set  >  0,  then  RTPACK  must  leave  room  for  this  data  respectively.  Also, 
PJLADD  and  RONDOAOD  will  be  maintained  by  RTPACK  to  tell  subsequent  PJL 
and  RONDO  Pack  routines  where  to  store  their  output. 

3.  XEOM  -  end  of  mission  flag 

4.  BMDCP(2]{3)  HRRTRN  reschedule 

5.  BMDCP(4)(5)  Hang  time  indications 

6.  ORDRMAKE/PJLIO  interaction. 

ORDRMAKE  makes  GIDQ's  whose  contents  are  mode  words.  A  zero  in 
GIDQ  instance  indicates  no  more  orders. 

Modes  1,3, 5, 7  search 

Modes  8*, 2, 4, 6  track 

*Note:  for  track  split  gate  000  mode  is  made  1000  so  an  invalid  end  of 
order  indication  will,  not  be  indicated. 

PJLIO  will  check  GIDQ  for  any  scheduled  returns. 

RTUNPK  will  check  modes  for  appropriate  track  or  search  decode. 

7.  PJLADD,  RONDOADD  will  be  maintained  fpr  PJLIO  by  RTPACK 
so  PJLORD  and  PJLROA  will  know  were  to  put  the  packed 
RONDO  AND  PJL  data. 
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3.  General  PJLIO  flow  chart 


^  START 


RESET 
VOP  CLOCK 


XMIT  ORDER 
BLOCK 


♦ 


SEPARATE 
RETURNS 
INTO  BINS 


RONOO 


k 


PAS 


IRIG 


PJL  Real-Time  proccssint) 


Make  next  equipment  orders 
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ORORMAKE  J 


_ t _ 

PACK  RADAR 
BASED  ON 
VDPOIJT//1H 


PACK  RADAR 


PACK  RONDO 


PACK  PJL 


PACK  CONSOL 


A.  IDENTIFICATION  EXECUTIVE  SURROUTINE 

TITLE;  PJL  CONTROL  CONSOLE  INTERFACE 

ID:  CC 

PROGRAMMER:  J.  J.  OGAN 

B.  FUNCTIONAL  DESCRIPTION 

This  routine  is  the  executive  interface  routine  for  consol  communication 
to  the  PJL  experiment.  Packed  input/output  is  via  the  common  areas  CCIN  and 
CCOUT.  PJL 10  uses  channel  command  words  to  dump  consol  input  data  into 
CCIN  and  transmit  consol  output  data  from  CCOUT. 

CC  has  two  basic  entry  points,  CONIN  and  CONOT,  used  to  accomplish  the 
basic  consol  input  and  output  respectively. 

C.  INPUT 

CCIN  -  20  bytes  of  input  data  are  dumped  into  this  area  whenever  PJLIO 
has  received  a  full  report  from  the  consol.  The  data  is  left  justified  in 
the  common  area  with  the  function  and  ID  bits  stripped  off  (total  of  six 
bits)  by  PJLIO. 

CONIN  will  process  each  word.  It  compares  each  of  the  five  input  words 
with  their  previous  values.  When  a  chanqe  is  sensed,  the  appropriate  unpack 
entry  point  will  be  iavolked.  These  entry  points  (INI  -  INS)  are  all  con¬ 
tained  in  the  subroutines  CCUNPK  (for  PJL). 

The  routine  ANDH  is  used  to  turn  those  bits  to  zero  in  the  INPUT  data 
that  are  return  to  zero  consol  parameters.  The  'modified'  consol  input 
words  are  then  stored  into  CCOIl  -  CC015  for  comparison  with  the  next  group 
of  5  consol  report  words. 

D.  OUTPUT 

CCOUT  -  80  bytes  of  output  data  are  dumped  into  this  area  to  be  trans¬ 
mitted  by  PJLIO  to  the  consol  display. 

The  data  is  properly  positioned  for  RCI  transmition  with  appropriate 
consol  identity  and  function  codes  (six  bits)  masked  into  the  high  six  bits 
of  each  word. 

CONOT  accesses  the  consol  output  data  in  PJLR  starting  at  C6SGNL  and 
ending  wi th  CECCOP. 

Proper  conversion  of  hexadecimal  count  ranges,  azimuths  and  elevations 
to  4  bit  BCD,  as  specified  in  consol  output  formats,  are  made  using  RTBCD, 
and  ANGBCD.  CONOT  uses  the  following  entry  points  in  CCPACK  to  make  the 
appropriate  consol  output  words: 
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0UT1P2 

C6SGNL 

NRL(3) 

NRG(4) 

C 2 DATA 


0UT3 

IDUM 

C7BUP 

C7BDWN 

NANGL 


0UT4 

C8ART 

C8ALFT 

NANGL 


OUTS 

C9TKCH 

C9GAIN 

IRBL 

ICBL 

C9WAIT 


PACKS  words  1  and  2  according  to  format 
signal  strength 

three  4-bit  BCD  range  digits  (Isb  =  1  meter), 
one  character  right  justified  in  3  half  words 

four  4-bit  BCD  range  digits  (Isb  =  IK  meter), 
one  charactrr  right  justified  in  4  half  words 

channel  access  -  bits  17,  16,  15  in  word  2 
of  consol  output.  This  field  was  not  on  the 
original  Sperry  consol  format  specification. 

PACKS  word  3  according  to  format 

Diode  fault  not  used  by  PJL 

Beta  limit  (up) 

Beta  limit  (down) 

4-bit  BCD  elevation  all  four  characters  in 
4  bytes. 

PACKS  word  4  according  to  fomtat 
Alpha  limit  right 
Alpha  limit  left 

4  bit  BCD  azimuth  all  4  characters  in  4 
bytes. 

PACKS  word  5  according  to  format 
active  channel  indicators 
manual  gain  operative 

Range  coast,  manual  range  track,  auto  range 
track  functionally  OR'ed  together. 

coast,  manual  track,  auto  track  functionally 
OR’ed  together 

standby 
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C9AAQ 

C9DESG 

C9L0CK 

C9nRKT 

C9WRIT 

0UT615 

(INPUT)  ICANT 
(INPUT)  ICABER 
(INPUT)  ICAA 
(OUTPUT)  lERRSP 

0UT1617 

NRL(3) 

CMULSY 

NRG(4) 

OUT  18 

NANGE 

OUT  19’ 

NANGE 

0UT20 

CATRK 


auto-acquisition 

Designate  ‘ 

Range  lock  on 
Break  track 
Record  data 

PACKS  words  6-15,  alpha  and  beta  errors 

not  presently  assigned 

beta  error  (10)  for  scope 

alpha  error  (10)  for  scope 

location  to  start  storage  of  ten  packed 
words  for  A  scope. 

PACK  words  16,  17 

three  4-bit  BCD  range  digits  for  A  SCOPE 
(Isb  =  1  meter),  one  character  right  justi¬ 
fied  in  3  half  words. 

multi -A  synch  bit 

four  4-bit  BCD  range  digits  (Isb  =  IK  meters), 
one  character  right  justified  in  four  half  words 

PACK  word  18 

4-bit  BCD  elevation  all  four  characters  in 
4  bytes. 

PACK  word  19 

4-bit  BCD  aximuth  for  multi  A  scope. 

PACK  word  20 

track  status  coast  status  not  used  in  PJL 
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E. 


SUBROUTINES  USED 


ANDH 

RTBCO 

ANGBCO 

IN1->IN5 

OUT  1 ->0015 

0UT615 

0UT1617 

0UT18-+-0UT20 

F.  CONSOL  READ/WRITE  CONTROL 


see  user  meinr  #21 

range  to  BCD  (4-bit) 

azimuth  or  elevation  to  BCD  (4-bit) 

(CCUNPK) 

(CCPACK) 


The  PJLRT  process  controls  reading  and  writing  from  the  consol  via 
communication  through  the  words  CECCIP  and  CECCOP  located  in  PJLO  static 
file. 


CEECIP  -  RESET  CC  for  input  from  the  360 

CECCOP  -  RESET  CC  for  output  to  the  360 

Various  routines  key  on  these  words.  One  is  considered  condition  on. 
Two  is  off.  RTPACK  (PJL  version)  will  pass  the  CECCIP  bit  condition  through 
the  GIOQ  for  later  us'e  by  PJLIO.  POLIO  will  detennine  if  it  should  have  re¬ 
ceived  consol  input  from  the  RCl. 

PJLIO  will  use  CEECOP  to  schedule  chained  control  words  which  will  in 
turn  actually  transmit  consol  orders  to  the  RCl. 

Presently,  the  PJL  process  is  alternating  read  write  cycles.  Timing 
problems  might  develop  when  the  PJL  processing  is  exercised  in  normal  mode 
with  35  ms  frame  times.  This  will  be  a  matter  of  experimentation.  However, 
as  long  as  enough  dead  time  is  available  after  the  last  TOT,  say  1  milisec, 
there  should  be  no  problem. 


0UT1P2 

C6SGNL 

NRL(3) 

NRG(4) 

C2DATA 


0UT3 

IDUM 

C7BUP 

C7BDWN 

NANGL 


0UT4 

C8ART 
COAL FT 
NANGL 


OUTS 

C9TKCH 

C9GAIN 

IRBL 

ICBL 

C9WAIT 


PACKS  words  1  and  2  according  to  format 

signal  strength  ' 

three  4-l)it  BCD  range  digits  (Isb  =  1  motor), 
one  character  right  justified  in  3  half  words 

four  4-bit  BCD  range  digits  (Isb  =  IK  mctor), 
one  character  right  Justified  in  4  half  words 

channel  access  -  bits  17,  16,  15  in  word  2 
of  consol  output.  This  field  was  not  on  the 
original  Sperry  consol  format  specification. 

PACKS  word  3  according  to  format 

Diode  fault  not  used  by  PJL 

Beta  limit  (up) 

Beta  limit  (down) 

4-bit  BCD  elevation  all  four  characters  in 
4  bytes. 

PACKS  word  4  according  to  format 
Alpha  limit  right 
Alpha  limit  left 

4  bit  BCD  azimuth  all  4  characters  in  4 
bytes. 

PACKS  word  5  according  to  format 
active  channel  indicators 
manual  gain  operative 

Range  coast,  manual  range  track,  auto  range 
track  functionally  OR'ed  together. 

coast,  manual  track,  auto  track  functionally 
OR'ed  together 

standby 


A.  IDENTIFICATION  SUBROUTINE 

TITLE;  PJL  CONTROL  CONSOL  PACK  INTERFACE 
ID:  CCPACK 

PROGRAMMER:  J.  J.  OGAN 
6.  FUNCTIONAL  DESCRIPTION 

This  routine  has  ten  entry  points  (OUTl,  0UT2,  0UT3,  OUT4,  OUTS, 
OUT615,  OUT1617,  0UT18,  0UT19,  0UT20)  each  of  which  will  pack  the 
number  of  consol  words  indicated  by  the  entry  name  into  the  consol 
output  common  area  CCOUT.  (i.e.,  0UT615  packs  words  6  through  15), 

These  packed  words  are  complete  with  consol  identity  code  (hex 
'8')  and  function  code  (binary  '00'). 

C.  INPUT 

All  inputs  are  via  calling  sequences  to  each  of  the  individual  entry 
points. 


d 
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C9AAQ 

C9DESG 

C9L0CK 

C9BRKT 

C9WRIT 

0UT615 

(INPUT)  ICANT 
(INPUT)  ICABER 
(INPUT)  ICAA 
(OUTPUT)  lERRSP 

0UT1617 

NRL(3) 

CMULSY 

NRG(4) 

OUT  18 

NANGE 

OUT  19  • 
NANGE 

0UT20 

CATRK 


auto-acquisi  tion 

Designate  j 

Range  lock  on 
Break  track 
Record  data 

PACKS  words  6-15,  alpha  and  beta  errors 

not  presently  assigned 

beta  error  (10)  for  scope 

alpha  error  (10)  for  scope 

location  to  start  storage  of  ten  packed 
words  for  A  scope. 

PACK  words  16,  17 

three  4-bit  BCD  range  digits  for  A  SCOPE 
(Isb  =  1  meter),  one  character  right  justi¬ 
fied  in  3  half  words. 

multi-A  synch  bit 

four  4-bit  BCD  range  digits  (Isb  =  IK  meters), 
one  character  right  justified  in  four  half  words. 

PACK  word  18 

4-bit  BCD  elevation  all  four  characters  in 
4  bytes. 

PACK  word  19 

4-bit  BCD  aximuth  for  multi  A  scope. 

PACK  word  20 

track  status  coast  status  not  used  in  PJL 
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D.  CALLING  SEQUENCE 


CALL  01JT1P2  (C6RNGE,  NRL,  NRG) 

CALL  0UT3  (IDIIM,  C7BUP,  C7BDWN,  NANGL) 

CALL  0UT4  (C8ART,  CBALFT,  NANGL) 

CALL  OUTS  (C9TKCH,  C9GAIN,  IRBL,  ICBL,  C9WAIT,  C9AAQ,  C9DESG, 
C9LOCK,  C9BRKR,  C9MRIT) 

CALL  OUT615  (ICANI(J),  ICABER(J),  ICAA(J),  lERRSP(J)) 

CALL  OUT1617  (NRL,  CMULS9,  NRG) 

CALL  0UT18(NANGL) 

CALL  OUT ’9  (NANGL) 

CALL  OUT  20  (CATRK) 


A.  IDENTIFICATION 


SUBROUTINE 


TITLE:  PJL  CONTROL  CONSOL  UNPACK 
ID:  CCUNPK 

PROGRAMMER:  J.  J.  OGAN 
B.  FUNCTIONAL  DESCRIPTION 

This  routine  has  five  entry  points  (INI,  iN2,  IN3,  IN4,  and  INS) 
each  of  which  will  unpack  one  of  the  five  4-byte  consol  input  words 
respectively.  In  addition,  they  access  the  consol  input  reqion  in  the  PJL 
static  file  starting  at  CIFAGL  and  ending  with  C5DESG,  and  store  consol 
parameters  into  the  file  as  necessary. 

It  is  on  this  level  that  device  pecular  parameters  are  checked  for 
reasonable  values.  For  example,  the  handwheel  fields  are  return  to 
<  2oro  peraineters  and  only  real  data  is  available  when  the  fields  are  non¬ 

zero. 

It  is  easy  to  find  these  parameters  by  looking  at  the  code.  If  a 
check  is  made  for  zero  before  storage  of  data  into  PJLR,  then  the  para¬ 
meter  is  a  return  to  zero  type. 

A  word  of  caution:  C3TKCH  is  a  break-before-make  switch. 

i  C.  INPUT 

CCIN  20  byte  common  control  console  input  area 

D.  OUTPUT 

CICAGL — ►  C50ESG,  control  console  input  section  of  PJLR 

E.  CALLING  SEQUENCES 

CALL  INI 
CALL  IN2 
CALL  IN3 
CALL  IN4 
CALL  INS 
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A.  IDENTIFICATION  SUBROUTINE 
TITLE:  PJL  MISSION  CLOCK  SERVICES 
ID:  CLOCK 

PROGRAMMER:  J.  J.  OGAN 

B.  FUNCTIONAL  DESCRIPTION 

Written  in  FORTRAN,  this  routine  allows  PJL  users  to  get  the  current 
mission  time  in  floating  point  seconds.  For  each  call  to  the  routine, 
CLOCK  will  access  the  BMDOS  mission  time  register  via  the  read  floating 
point  time  macro  (RDFLTM). 

C.  INPUT 

No  formal  parameter  inputs 

D.  OUTPUT 

Eight  bytes  (double  precision)  floating  point  mission  time  are 
stored  in  user  supplied  address  area. 

E.  CALLING  SEQUENCE 

CALL  CLOCK  (SYSTEM) 

Where  SYSTEM  is  pointer  to  address  to  store  mission  time. 

F.  MISCELLANEOUS 

Timer  resolution  is  13,6  u  sec.  The  constraint  being  levied  by  the 
OS-360  13.6  u  sec  interval  timer. 
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A.  IDENTIFICATION  PROCESS  INITIALIZER 

TITLE:  MASTER  PJL  CONTROL  4 

ID:  MASTER 

PROGRAMMER:  C.  BLACKWELL 

B.  FUNCTIONAL  DESCRIPTION 

The  bask  version  of  iiiasLer  has  been  drastically  modified  for 
use  in  initiating  the  PJLIO/PJLRT  process. 

This  new  master  1)  schedules  the  initial  mission  start  time 

2)  calls  PJLINT  to  initialize  the  RTl  array  in  PJLl) 

3)  calls  PJLPMI  to  initialize  the  PJLRT  post-mission  array 

4)  starts  the  mission  clocks 

5)  schedules  recording  by  setting  C5WRIT  =  1  in  PJLR 

6)  schedules  PJLIO  for  real-time  processing 

7)  schedules  WLC  for  Interrupted  real-time  processing. 
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A.  IDLNTIFICATION  SUBROUTINE 
TITLE:  PJL  IRIG  INTERFACE  {WSMR  TIME) 

ID:  PJIRIG 

PROGRAMMER:  T.  R.  COTTIER 

B.  FUNCTIONAL  DlSCRIPTION 

This  routine  accesses  the  IRIGBIN  in  PJLIO  which  contains  the  WSMR 
time  message  (8  bytes),  unpacks  the  message,  accesses  the  WSMR  time  area 
in  PJLR,  and  stores  the  raw  unpacked  WSMR  time. 

Cells  affected  in  PJLR  are 

WISEC  -  raw  White  Sands  second 

WIMS  -  raw  White  Sands  milliseconds 

WITME  -  raw  White  Sands  tenths  of  seconds 

C.  INPUT 

IRIGBIN  maintained  by  PJLIO 

D.  OUTPUT 

WISEC,  WIMS,  WITIME  in  PJLR. 

E.  CALLING  SEQUENCE 

CALL  PJIRIG 
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A.  IDENTIFICATION  STATIC  FILE 

TITLE:  PJL  ORDERS  FILE  (STATIC) 

ID:  PJLO 

PROGRAMMER:  J.  J.  OGAN 
n.  FUNCTIONAL  DESCRIPTION 

PJLO  is  the  machine  implementation  of  the  PJLRT  ORDERS  file  as 
described  in  the  SIJRC  interface  document  with  minor  additions. 

Briefly,  PJLO  is  a  description  of  a  static  load-time  fixed  area 
in  core  to  be  used  as  the  primary  interface  for  transfer  of  order  in¬ 
formation  from  the  PJL  process  to  BMDOS  and  ultimately  the  radar  sub¬ 
systems,  PJL  equipment,  RONDO  A,  and  consol. 

With  the  exception  of  TIMOTR  (which  is  REAL*8)  all  data  in  PJLO 
is  INTEGERM. 

At  load  time,  all  information  in  PJLO  is  set  to  0. 

C.  FILE  DESCRIPTION 


RTI  this  is  a  baisc  real-time  initialization  array  used  by  the 

PJLRT  process  to  establish  basic  variable  run-time  parameters. 
During  the  initialization  of  the  PJL  process,  MASTER  will  call 
PJLINT  which  will  read  run-time  parameters  from  cards  and 
store  them  into  the  RTI  array. 

XEOM  This  single  4-byte  word  is  used  by  PJLRT  to  communicate  to 
PJLIO  the  termination  of  the  run. 

=  0  continue  with  run 
=  1  end  run 


BMDCP 


this  array  called  BMD  control  parameter  array  is  used  to 
pass  schedule  and  hang  information 


BMDCP(l)  =  not  used 
BMDCP (2)1^ 


BMDCP (3)/' 


floating  point  mission  time  in  seconds  for  PJLIO 
process  to  reschedule  itself  for  execution 


BMDCP  (4)1 


BMDCP(5) 

BMDCP(6y 
BMDCP(7) 
BMDCP (8) 
BMDCP (9) 


(>=  length  of  hang  duration  is  floating  point  seconds 


=  spares 


TlMOTR(l)  =  floating  point  (REALM),  §  of  orders 
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TIM0RT(2) 

I 

TIM0TR(17) 


VDPOUT  (1,1) 


VDPOUT 

BSUOUT 

PJLOUT  (1,1) 


PJL01JT(2,1) 

I 

PJLOUT(15,l) 


RONDOT(l,l)  = 


R0ND0T(2,1) 

I 

RONUOT(13,l) 


C6SGNL 

CMULSY 

CEASCP  ] 
CESCER  } 
CECCIP 
CECCOP  J 


Up  to  16  time-of-transmition  (TOT's)  in 
floating  point  mission  time  > 


INTEGCRM,  II  of  orders  this  coll  is  iiu infii ined 
by  PJLRT  and  is  actually  used  by  KII’ACK  (P.JL 
version) 

Up  to  16  valid  orders  for  the  VDP 

Up  to  16  valid  orders  to  the  BSU 

PJL  equipment  schedule  information 
=  0  no  PJL 

=  1  PJL  data  this  cycle 

this  information  is  used  by  RTPACK  and  PJLIO 


One  PJL  equipment  order.  Double  subscripting 
has  been  used  to  allow  for  later  expansion  to 
multiple  PJL  orders  during  one  frame. 

RONDO  A  equipment  schedule  information 

=  0  no  RONDO 
=  1  RONDO  data  this  cycle 

this  information  is  used  by  RTPACK  and  PJLIO 


One  RONDO  equipment  order.  Double  subscripting 
has  been  used  to  allow  for  later  expansion  to 
multiple  PJL  orders  during  one  frame. 


One  consol  order 


external  function  schedule  words  for  the  CC-EF 
external  function  consol  word.  CECCIP  and  CECCOP 
are  of  particular  importance.  CECCIP  controls 
reset  control  consol  for  input  from  the  360/6b. 
CECCOP  controls  reset  control  consol  for  output 
to  the  360/65. 

PJLRT  makes  his  consol  scheduling  wished  known 
to  PJLIO  through  these  words.  =1  value  for  the 
external  functions  selects  the  option.  =0  desig¬ 
nates  no  selection. 
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A.  intNTIFICATION 


STATIC  FILE 


TITLE:  PJL  RETURNS  FILE  (STATIC) 

ID:  PJLR 

PROGRAMMER:  J.  J.  OGAN 

B.  FUNCTIONAL  DESCRIPTION 

PJLR  is  the  machine  implementation  of  the  PJLRT  returns  file  as 
described  in  the  SURC  interface  document. 

PJLR  is  a  description  of  a  static,  load-time  fixed  area  in  core  to  be 
used  as  the  primary  interface  for  transfer  of  return  information  from  the 
radar  sub-systems,  the  PJL  Equipment,  RONDO  A  and  the  consol  to  the  PJLRT 
process. 

All  information  in  PJLR  is  INTEGER*4  format. 

At  load  time,  all  information  in  PJLR  is  set  to  0. 

C.  FILE  DESCRIPTION 

VDPIN  =  Space  for  up  to  sixteen  returns  from  the  VDP  (unpacked) 

BSUIN  =  Spaqe  for  up  to  sixteen  returns  from  the  BSU  (unpacked) 

PJLIN  =  Space  for  one  report  of  480  bytes  from  the  PJL  equipment 

(unpacked) 

RONDOI  =  Space  for  one  report  of  16  bytes  from  the  RONDO  A  remote 

radar  (unpacked) 

C1FA6L 

I  =  Space  for  one  complete  unpacked  consol  return 

C5DES6 

PIRN6E 

I  =  Space  for  one  unpacked  PAS  data  return 

PHD 

WISER 

I  =  Space  for  one  range  time  return  (unpacked) 

WiriME 

NULLE  =  An  extra  'sneak'  word  slipped  in  by  PJLRT  for  no  known 
reason. 
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DVCERR 


=  An  array  to  pass  information  concernint]  the  various 
returns  from  the  various  subsystems  and  equipinent. 

The  following  code  convert! on  is  followed: 

=  -1  devise  error  for  some  unspecified  reason 
=  0  no  return  this  cycle  from  this  eciuipmoril. 

=  1  valid  data  has  been  received,  unpacked  and 
stored  in  the  appropriate  regions  in  PJLR. 

Device  code  slots  have  been  assigned  in  the  following 
manner: 

DCCERR  (1)  =  VDP 

(2)  =  BSU 

(3)  =  CONSOL 

(4)  =  RONDO  A 

(5)  =  RONDO  B  (not  used) 

(6)  =  PJL  Equipment 

(7)  =  ROT  (PAS)  report 

(8)  =  WSMR  TIME 

(9)  -  (13)  SPARE 

'  -  another  sneaky  word 


NULL3 


lOCNTinCATION 


SUBROUTINE 


TITLE:  PJL  EQUIPMENT  ORDERS  INTERFACE 
ID:  PJLORD 
PROGRAMMER:  J.J.  Ogan 
riJNCTIONAL  DESCRIPTION 


When  called  with  proper  address  pointers,  this  routine  will 
commence  PJL  parameter  packing  from  the  PJLO  static  file  [starting 
address  -  PJLOUT  (2,1)]  and  return  as  output  four  packed  PJL 
equipment  order  words  as  specified  in  the  SIJRC  interface  document. 

INPUT/OUTPUT 

Calling  Sequence  for  PJLORD  is 

CALL  PJLORD  PJLOUT  (2,1),  IPACK 

(INPUT)  PJLOUT  =  F.W.A.  of  unpacked  PJL  equipment  orders  in  PLJO 
file. 

(OUTPUT)  IPACK  =  F.W.A.  of  location  to  begin  storage  of  16  bytes 
packed  PJL  equipment  orders. 

MISCELLANEOUS  commits 

Bits  0-12  in  each  of  the  4  order  words  to  the  PJL  equipment 
are  left  justified  in  the  data  portion  of  the  RCI  commands 
instead  of  right  justified  as  one  might  suppose  from  SURC's 
interface  document. 


EXAMPLE: 


31- 


-26 


25- 


0 


RCI  WORD  ID/FUNCT.  DATA  PORTION  0—0 


PJL  DATA  LEFT 
JUSTIFIED  IN 
THIS  FIELD 


Make  sure  starting  input  address  is  PJLOUT  (2,1) 

PJLOUT  (1,1)  is  a  key  call  to  instruct  PJLIO  that  PJL  equipment 
orders  are  scheduled  (=1)  or  not  scheduled  (-o). 
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A.  IDENTIFICATION  SUBROUTINE 
TITLE:  PJL  PASSED  DATA  INTERFACE 
ID:  PJLPAS 

PROGRAMMER:  J.  J.  Ogan 

B.  FUNCTIONAL  DESCRIPTION 

When  called  with  proper  address  pointers,  this  routine  will 
unpack  PAS  parameters  and  store  them  into  the  PAS  return  area  in 
PJLR.  This  area  starts  with  the  variable  PIRNGE  and  ends  with  PHD. 

C.  INPUT/OUTPUT 

Calling  sequence  for  PJLPAS  is 
CALL  PJLPAS  (PASBIN,  PIRNGE) 

(INPUT)  PASBIN  =  address  pointer  to  packed  PAS  return  as  sorted 
by  PJL  10. 

(OUTPUT)  PIRNGE  -  address  pointer  to  starting  location  for  storage  of 
unpacked  PAS  parameters  of  range,  azimuth,  elevation, 
time  tag,  status  and  id. 

D.  MISCELLANEOUS 

None  • 
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A.  IDENTIFICATION 


SUBROUTINE 


TITLE:  PJL  RONDO  "A"  Orders  INTERFACE 
ID:  PJLROA 

PROGRAMMER:  J.  J.  Ogan 

B.  FUNCTIONAL  DESCRIPTION 

When  called  with  proper  address  pointers,  this  routine  will 
coiiiiiience  RONDO  parameter  packing  from  the  PJLO  static  file  [starting 
address  RONDOT  (2,1)]  and  return  as  output  four  packed  RONDO  A 
order  words  (16  bytes)  as  specified  in  the  SURC  interface  document. 

C.  INPUT/OUTPUT 

Calling  sequence  for  PJLROA  is 

CALL  PJLROA  RONDOT  (2,1),  IPACK 

(INPUT)  RONDOT  (2,1)  =  address  pointer  to  location  in  which  to  start. 

packing  RONDO  orders. 

(OUTPUT)  IPACK  =  location  to  store  16  bytes  of  packed  RONDO  order  data, 
D  MISCELLANEOUS 

Be  careful  that  the  first  input  address  to  start  order  access  is 
RONDOT  (2,1).  RONDOT  (1,1)  is  a  key  call  to  instruct  PJLIO  that 
RONDO  is  scheduled  (=1)  or  not  sch'^duled  (=o). 


A.  IDENTIFICATION 

TITLE:  PJL  RONDO  "A"  RETURNS  INTERFACE 
ID:  PJLRRA 

PROGRAMMER:  J.J.  Ogan 

B.  FUNCTIONAL  DESCRIPTION 

This  routine  is  used  to  unpack  a  RONDO  A  return  stored  in  the 
RONDOBIN  in  PJLIO  and  transfer  its  parameters  to  the  RONDO  A  return 
area  [starting  at  RONDOI  (1,1)1  in  PJLR. 

C.  INPUT/OUTPUT 

Calling  sequence  for  PJLRRA  is 

CALL  PJLRRA  RONDOBIN,  RONDOI  (1,1) 

(INPUT)  RONDOBIN  =  address  pointer  to  packed  return  (16  bytes)  as 
sorted  by  PJLIO. 

(OUTPUT)  RONDOI  ®  address  pointer  to  starting  location  for  parameter 
storage  into  the  PJLR  RONDO  return  area  as  specified 
in  the  SURC  interface  document. 

D.  MISCELLANEOUS 

All  unpacking 'is  based  on  normal  distribution  in  the  RCI  word  with 
6  high  order  bits  of  ID/function,  18  bits  of  raw  data,  and  8  bits  of 
low  order  zero. 

No  attempt  is  made  to  store  1  or  0  in  RONDOT  (1,1)  (3,1), 

(5,1),  (10,1)  as  shown  in  the  SURC  interface  document. 

This  has  not  affected  the  operation  of  PJLRT  in  anyway. 
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A.  IDENTIFICATION  SUBROUTINE 

TITLE:  PJL  EQUIPMENT  RETURNS  INTERFACE 
ID:  PJLRTN 

PROGRAMMER:  J.  J.  Ogan 

B.  FUNCTIONAL  DESCRIPTION 


This  routine  will  unpack  a  PJL  equipment  rturn  stored  in  the 
PJLBIN  array  in  PJLIO  and  transfer  its  parameter  to  the  PJL  return 
area  [starting  at  PJLIN  (1,1)1  in  PJLR. 

C.  INPUT/OUTPUT 


Calling  sequence  for  PJLRN  is 


CALL  PJRTN  (PJLBIN,  PJLIN) 

(INPUT)  PJLBIN  =  address  pointer  to  packed  return  (4B0  bytes)  as  sorted 
by  PJLIO. 

(OUTPUT)  PJLIN  =  address  pointer  to  array  in  which  store  to  unpacked 
returns  as  specified  in  the  SURC  interface  document. 


D.  MISCELLANEOUS 

All  32  bits  are  utilized  with  PJL  equipment  returns. 

’  31 - 28  27 - 0 


RCI/PJL 


ID  =  "F" 


PJL  DATA 


This  is  different  from  other  returns  where  the  high  6  bits 
and  the  low  eight  bits  are  thrown  away. 


\ 
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A.  IDENTIFICATION 


SUBROUTINE 


' 


TITLE;  PJL  TAPE  READ  ROUTINE 
ID:  PJTAPE 

PROGRAMMER:  J.  J.  Ogan 

B.  FUNCTIONAL  DESCRIPTION 

This  routine  was  created  for  two  reasons: 

a)  to  relieve  the  PJL  applications  programmer 
burden  on  a  VB  tape  using  FORTRAN  I/O  access 
methods . 

b)  to  functionally  provide  one  PJL  logical  record 
of  information  for  each  individual  call  to  the 
routine.  This  was  necessary  because  after  any 
one  real-time  run,  the  data  link  has  a  combination 
of  PJL  data  and  BMDOS  performance  monitor  records, 

PJTAPE  uses  READOK  to  effect  its  physical  I/O.  READDK  rcturtis 
one  logical  record  for  each  call.  This  logical  record  still  has  tiie 
record  descriptor  word  (RDW). 

PJTAPE  will  look  for  the  PJL  identifier  would  "PJLR"  in  bytes 
4-8  of  the  logical  record.  If  found,  PJTAPE  will  strip  the  ROW  and 
pass  the  remaining  part  of  the  logical  record  to  the  caller. 

If  the  record  'is  not  PJL  the  routine  will  loop  until  one  is 
found  or  end-of-file  is  sensed. 

PJTAPE  also  supports  a  rewind  capability. 

C.  INPUT/OUTPUT 

Calling  sequence  for  PJTAPE  is 

CALL  PJTAPE  (LUN,  MODE,  lADD,  IND,  NW,  BS) 

(INPUT)  LUN  =  logical  unit  §  (not  used) 

(INPUT)  MODE  =  mode  to  read  tape  (not  used) 

(OUTPUT)  lADD  =  location  to  store  stripped  logical  PJL  record 

(OUTPUT)  IND  =  indication  of  results  of  read  operation 
=1  incomplete  read  (not  used) 

-2  read  OK  no  errors 
=3  end-of-file  on  tape 

=4  read  complete,  error  occurred,  data  in  doubt 
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C.  INPUT/OUTPUT  CONT'D. 


(OUTPUT)  NW  =  number  of  bytes  in  this  PJL  logical  record 

(INPUT)  BS  =  rewind  requester 
=0  no  rewind 
=1  rewind 

0.  MISCELLANEOUS 

The  first  call  to  PJTAPE  will  result  in  a  call  to  OPENOK  which 
will  open  the  DCB  for  the  data  link  tape.  OPENOK  is  an  entry  point 
along  with  READDK  in  the  subroutine  DLINKR. 


A.  IDENTIFICATION 


SUBROUTINE 


TITLE:  REAL  TIME  HAPDAR  ORDER  PACKER 

ID:  RTPACK 

PROGRAMMER:  J.  J.  OGAN 
B.  FUNCTIONAL  DESCRIPTION 

RTPACK  was  modified  from  the  BASIC  real-time  HAPDAR  software  to 
acconiiiodate  PJL  software  needs.  The  new  PJL  RTPACK  accesses  the  PJLO 
(radar  portions)  to  get  up  to  16  basic  raw,  unpacked  coiiiiiiands  for  HAPDAR. 

Portions  of  interest  are 

TIMOTR  -  times  of  transmition,  scheduled  VDP  trigger  times 

VDPOUT  -  scheduled  commands  for  the  VDP 

BSUOUT  -  scheduled  commands  for  the  beam  s tearing  unit 

PJLRT  stores  into  VDP0UT(1  ,l)aninteger  It  from  1  to  16  which  is  used 
by  RTPACK  to  determine  number  of  orders  scheduled  for  any  one  frame. 

For  any  one  order  to  the  sub-units  of  HAPDAR, the  RTPACK  routine  will 
select  one  TOT,  one  set  of  VDP  commands  and  one  set  of  BSU  commands  as 
described  in  the  SURC 'interface  document.  Casual  inspection  reveals  this 
set  of  commands  is  a  subset  of  all  possible  command  parameters.  As  a  rule, 
any  parameters  not  used  in  the  PJL  processing  will  in  the  final  packed  orders 
be  zeroes. 

A  major  accommodation  made  in  RTPACK  for  PJL  processing  is  the  capabi¬ 
lity  to  leave  room  in  the  orders  buffer  for  RONDO  and  PJL  orders  if  need. 

RTPACK  has  scheduling  information  concerning  RONDO/PJL  in 

R0ND0T(1,1)  and  PJLOUT  (1,1)  RTPACK  scheduling  MATRIX 


CONDITIONS 


R0NU0T(1,1) 

0 

I 

0 

1 

PJL0UT(1,1) 

0 

0 

1 

1 

Bytes  re¬ 
served  by 
RTPACK 

0 

16 

16 

32 
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Depending  upon  which  matrix  condition  is  valid  for  any  one  cycle, 

RTPACK  will  leave  room  for  none,  either  one,  or  both.  On  any  one  cycle 
a  maximum  of  one  order  per  RONDO/PJL  device  is  valid.  These  orders  are  v 

always  located  ..t  the  beginning  of  the  order  block  before  any  orders 
for  HAPDAR  subunits  are  packed. 

The  space  left  for  RONDO  and  PJL  be  filled  by  appropriate  calls  to 
PJLROA  and  PJLORD  in  the  10  executive  PJLIO.  This  PJL  version  of  RTPACK 
will  send  no  liSU  diode  test  words. 

The  PJL  version  of  RTPACK  has  been  modified  to  support  transinition 
of  XS-3  character  line  messages  to  be  transferred  to  the  RONDO  B  port 
on  the  RCI  (actually  connected  to  the  printer). 

Three  characters  per  cycle  of  PJLIO/RTPACK  are  sent  to  the  RCI.  Tor 
further  details  on  the  1218  printer  support  see  documentation  on  the  rou¬ 
tine  TTYOUT  and  the  general  discussion  of  1218  on-line  printer  capabilities 
in  the  general  discussion  of  RCA/PJL  interface  software.  For  consol  sched¬ 
uling  purposed  RTPACK  places  read /write  information  in  the  CC-EF  word 
inforporated  in  the  last  radar  output  order.  Extensive  experimentation,  on 
both  RCA  and  SURC's  part,  has  shown  that  SURC  should  at  least  alternate 
scheduling  of  consol  reads  and  writes. 

The  last  major  difference  in  the  PJL  RTPACK  routine  is  that  all  accessed 
raw  data  is  already  in  integer  count  form  and  need  not  to  be  run  through 
floating  to  fix  scaling  conversions. 

The  basic  philosophy  of  sequence  of  order  words  to  the  VDP  and  BSU 
has  been  kept  consistent  with  that  employed  in  the  basic  real-time  HAPDAR 
software. 
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A.  IDENTIFICATION 

TITLE:  REAL  TIME  HAPDAR  UNPACK 

ID:  RTllNPK 

PROGRAMMER:  J.  J.  OGAN 

B.  FUNCTIONAL  DESCRIPTION 

RTUNPK  has  been  modified  for  PJL  interface  support  in  two  major  ways: 

One,  all  data  is  stored  into  the  radar  return  areas  of  PJLR  namely 
VDPIN.  This  is  a  significant  departure  from  the  re()ular  process  of  storing 
unpack  data  into  dynamic  SROQ's  and  TROQ's. 

The  second  major  difference  is  that  all  unpack  data  is  stored  into 
PJLR  in  a  raw  binary  count  form  leaving  the  fix  to  float  conversion  to  the 
PJL  tactical  software.  (The  reader  will  recall  that  integer  count  data 
was  also  passed  to  RTPACK).  Integer  interfaces  are  maintained  in  this 
manner  to  afford  a  more  realistic  dividing  line  between  RCA  interface  sup¬ 
port  software  and  PJt  tactical  real-time  software. 

Track  return  or  search  return  information  is  determined  through  access 
of  the  GIDQ  in  the  same  manner  as  the  BASIC  software  only  in  this  case  Kie 
actual  mode  code  associated  with  this  order/returti  pair  is  stored  in  the 
GIDQ  slots  instead  of;^  using  GID  pointer  addresses. 

This  special  GIDQ  is  made  by  the  ORDRMAKE  logic  in  PJLIO. 


A3-45 


4 


A.  IDENTIFICATION  SUBROUTINE 

TITLE:  PJL  TAPE  SAVE  DATA 

ID:  TAPESV 

PROGRAMMER:  C.  W.  ZIEGLER,  JR. 

B.  FUNCTIONAL  DESCRIPTION 

To  support  PJL  data  link  recording  needs,  the  BASIC  real-time  WRITDL 
tape  routine  was  modified  in  the  following  manner: 

An  additional  entry  point  for  PJL  was  added  to  WRITDL  called  TAPESV. 
This  new  entry  supports  a  slightly  different  calling  sequence. 

Any  call  to  this  entry  point  will  result  in  an  overhead  of  8  bytes 
of  identification  tagged  on  to  each  logical  record.  This  will  enable 
proper  handling  of  PJL  data  by  PJPMl,  the  reduction  program. 

These  eight  bytes  of  overhead  are  as  follows: 


12  3  4 


'P 

J 

L 

R' 

n 

-0 

u 

'PJLR'  will  be  in  core  as  hexadecimal 
D7D1D3D9i6 

ID  will  be  a  binary  number,  0-50,  passed  through  the  TAPESV  calling 
sequence. 

C.  INPUT/OUTPUT 

Calling  Sequence  for  TAPESV 

CALL  TAPESV(IA0D,NBYTE,IRC,ID) 

(INPUT)  lADD  =  address  to  start  recording  starting  in  a  full  word 
boundary 
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(INPUT)  NBYTE  =  number  of  bytes  to  be  recorded 

(OUTPUT)  IREC  =  indicator  of  recording  status 

IRC  =  0  recording  is  OK 

IRC  =  1  buffer  is  full  (no  action  taken,  waiting  for 
tape) 

IRC  =  2  record 

IRC  =  3  call  made  to  TAPESV  with  record  button  off 

(INPUT)  ID  =  binary  ID,  0-50,  for  purposes  of  PJL  record  distinction. 
D.  MISCELLANEOUS 

Calls  to  TAPESV  with  the  C5WRIT  parameter  in  PJLR  turned  off  will 
result  in  data  transfer  to  recording  buffers,  however,  no  physical  recording 
of  data  will  be  executed.  Maximum  record  size  supported  is  determined  by 
the  BUFMAX  field  in  the  operational  version  of  1OBUF0.  The  BUFMAX  is  cur¬ 
rently  16,304  bytes  or  4,096  words. 

Two  different  versions  of  TAPESV  exist.  One  for  interrupted  real-time 
operation  and  one  for  real-time  operation. 

The  interrupted  real-time  version  stops  the  mission  time  and  transfers 
control  to  0/S  for  the  actual  physical  tape  operations. 

All  block  discriptor  and  record  descriptor  conversions  follow  those 
used  with  IBM  VB  logical  records. 
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A.  inENTIFICATION  SUBROUTINE 

TITLE:  TTY  OUTPUT 

ID:  TTYOUT 

PROGRAMMER:  J.  J.  OGAN 

B.  FUNCTIONAL  DESCRIPTION 

It  is  desireable  to  be  able  to  print  during  real-time  messages  on  the 
121B  printer.  Making  use  of  the  fact  that  RONDO  B  port  for  the  RCl  has 
been  connected  to  a  portion  of  the  1218  memory,  it  is  functionally  very 
simple  to  get  to  the  1210  printer. 

This  routine  makes  up  a  standard  XS-3  coded  line  message  complete 
with  proper  RCI  ID/function  code  for  sending  information  to  RONDO  B  port. 

C.  INPUT/OUTPUT 


The  calling  sequence  to  TTYOUT  is: 


CALL 

TTYOUT (IMES.ILEN) 

(INPUT) 

IMES  = 

t 

the  address  of  the  first  word  of  the  desired 
message  to  be  displayed  on  the  12IH  prif)ter 
(4  characters’/word ;  standard  S/360  8-bit  code) 

(INPUT) 

ILEN  = 

the  number  of  characters  in  the  messacie  (max 
allowed  is  255) 

Output  is  to  an  array  in  core  addressible  from  outside  of  TTYOUT. 

The  data  in  the  core  array  is  a  grouping  of  three  characters  (in  XS-3 
code)  per  4  bytes  of  core  with  appropriate  RONDO  B  ID  and  function  codes. 

For  example:  call  TRYOUT  with  the  message  'PJL'  (in  hex  D7D103)  and 
the  routine  would  convert  these  characters  to  XS-3  code  and  eventually  make 
the  word  D2A92600 

Broken  dov/n  it  looks  like  this 


D  2  A  9  2  6  0  0 


1011 

f 


00  10 


1010 


0000 


0000 


RONDO  FUNC  P  J  L  — ^in  XS-3  code 

B 

ID 
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TTYOUT  makes  the  assumption  that  any  one  call  to  it  constitutes  one 
line  of  data  for  the  1218  printer.  By  agreement  between  Sperry  and  RCA, 
a  $$$  in  XS-3  code  is  to  be  sent  to  flag  end-of-line.  Therefore,  TTYOUT 
will  tag  $$$  into  the  end  of  every  message.  Also  for  further  separation 
a  ///  is  added  to  the  beginning  of  every  message. 

D.  SYSTEM  INTERACTION 

RTPACK  is  responsible  for  taking  one  full  word  out  of  the  TTY  output 
array  (i.e.,  transinition  of  3  characters/cyclo)  .  Since  the  TTYIUJF  is 
initially  filled  with  timeouts{ '20000000* ),  RTPACK  will  pack  time  outs. 

When  and  if  data  is  dumped  into  TTYBUF  by  TTYOUT,  RIPACK  iminediatly  begins 
to  pick  up  valid  RONDO  B  transmition  words.  Once  a  word  is  fetched  from 
TTYBUF,  RTPACK  stores  a  time  out  back  into  the  cell.  PJLIO,  ineanwhiles, 
has  soft-wired  CCW's  that  will  pick  up  the  one  word  RTPACK  has  managed 
to  service  with  the  most  recent  information  for  the  1218. 

E.  DATA  CAPACITIES/RATES 

TTYOUT  can  support  a  1500  character  burst  backlog  before  it  will 
loop  back  on  itself  and  destroy  the  oldest  data  not  transferred. 

Presently, the  PJL  process  is  set  up  to  transfer  3  characters/cycle 
so  a  1500  burst  backlog  would  take  500  cycles  to  transfer  over  to  the 
1218  computer. 

One  additional  constraint  to  keep  in  mind  is  that  the  1^18  can  pro¬ 
bably  only  support  2  lines/sec  maximum  before  data  messages  start  getting 
scrambled.  This  implies  that  with  a  100  millisecond  frame  (for  example)  the 
message  lengths  should  be  at  least  15  characters  (remember  6  characters  of 
overhead;  111  and  $$$). 

For  basic  flAPDAR  software  with  20  millisecond  frame  times,  75  charac¬ 
ter  messages  would  be  advised. 

The  whole  point  of  this  being  --  watch  the  burst  data  rate  (give  the 
TTYOUT  /RTPACK  team  time  to  catch  up)  and  avoid  message  scramble  with 
appropriate  length  messages. 

F.  MISCELLANEOUS 

TTYOUT  will  support  all  length  messages  from  1  to  255  characters. 

When  #  characters  is  not  module  3, the  routine  will  pad  to  the  right  blanks 
to  make  a  module  3  count.  A  message  of  >  255  characters  will  have  only  the 
first  255  sent. 
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A. 


IDENTIFICATION 


IRT  CONTROL  EXECUTIVE 


TITLE:  POL  CONTROL  EXECUTIVE  FOR  IRT 
ID:  WLC  (PJL  VERSION) 

PROGRAMMER:  J.  J.  OGAN 
B.  FUNCTIONAL  DESCRIPTION 

The  basic  WLC  has  been  modified  significantly  to  control  the  PJL 
processing  in  IRT.  The  SURC  software  was  ideally  set  up  for  IRT  opera¬ 
tion  with  PJLSIM  and  PJLRT  working  as  independent  units  sharing  the 
basic  common  areas  known  as  PJLO  and  PJLR.  WLC  is  a  very  dumb  executive 
that 


(1)  Calls  PJLRT  process 

(2)  Stops  clocks 

(3)  Calls  PJLSIM 

(4)  Calls  PJLCON  which  simulates  consol  input  via  cards 

(5)  Calls  PJLPRT  to  enable  display  of  results  from  previous 
real-time  cycle 

t 

(6)  Starts 'up  clock 

(7)  Reschedules  itself  based  upon  the  mission  time  passed 
through  BMDCP  (2),  (3). 

The  interrupted  real-time  processing  allows  SURC  to  check  out  tacti¬ 
cal  modifications  to  PJLRT  without  wasting  valuable  computer  time  and 
equipment  time  and  have  the  I/O  facilities  of  0/S  available  for  extensive 
printer  display. 

In  reality,  this  IRT  process  has  been  run  very  little;  the  primary 
benefit  being  derived  during  the  initial  attempts  to  run  PJLRT  under  BMDOS. 
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